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FOREWORD 


The Logistics of Orbital Vehicle Servicing (LOVES) Computer 
Specification was developed as a part of Study 2. 6, Operations Analysis. 

Under this study, a number of alternatives to improve utilization of the 
Space Shuttle and the Tug were investigated. Preliminary results have 
indicated that space servicing offers a potential for reducing future operational 
and program costs over ground refurbishment of Satellites. This specifica- 
tion defines a computer code which could be developed to simulate space 
servicing, and it is proposed that this computer code be a part of a follow-on 
to Study 2, 6 during FY 1974. 

This volume is one of four volumes comprising the final report for 
the FY 1973 effort on Study 2. 6. The four volumes are: 

Volume I Executive Summary 

Volume II Analysis Results 

Volume III Payload Designs for Space Servicing 

Volume IV LOVES Computer Code Specification 

Study 2. 6 Operations Analysis is one of several study tasks conducted 
under NASA Contract NASW-2472 in FY 1973. The NASA Study Director was 
Mr. V. N. Huff, NASA Headquarters, Code MTE. 
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1. INTRODUCTION 


Under Study 2. 6, Operations Analysis, several alternatives were 
investigated to improve utilization of the Space Shuttle and the Tug upper 
stage. These included increased multiple payload deployment and retrieval 
operations, orbit plane change maneuvers, and other options. Results of 
these efforts led to consideration of space servicing as a means of improving 
Shuttle /Tug utilization. 

The study also promoted a better appreciation for the Tug capabilities 
which should eventually result in a better utilization. For example, the space 
servicing approach reduces the weight carried to orbit to accomplish the 
mission and allows packaging in small increments which should certainly 
improve the loading of the Tug and Shuttle. Space servicing also strongly 
supports standardization of subsystems which can potentially reduce RDT&E 
and unit-recurring costs. 

In order to analyze the concept of space servicing, it is first neces- 
sary to perform a statistical analysis of the failure characteristics of all 

! 

payloads to be serviced. The large volume of space traffic projected 'for 
the time period of interest, the demands on the logistics fleet which must be 
integrated with other flight requirements, and the high degree of detail neces- 
sary to simulate space servicing all tend to favor a computer simulation as 
the appropriate study tool. 

This computer simulation will treat a variety of payloads: expend- 
able, retrievable, and serviceable. Traffic in the mission model is to be 
examined, and each spacecraft will be placed in one of the three groups. The 
computer program will simulate the placing of all spacecraft in orbit and the 
servicing or retrieval of spacecraft that have passed their useful life, depleted 
their expendables, suffered failures in critical components, or experienced 
degraded operation or reliability. 

Ground operations will also be simulated. This includes decisions 
defining which items are to be loaded on each Tug and when each flight should 
be made. Scheduling to develop maximum utilization of available resources 
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is desirable in. view of the limited supply of Tugs, Shuttles, and Space 
Replaceable Units (SRUs). 

The computer program will be used to study such parameters as 
the number of launch vehicles required, the number of flights required, the 
outage time of various satellites, and the effects of various policies on 
these parameters as well as program costs. The simulation w ill treat each 
satellite vehicle and each launch vehicle as a discrete element. The satellite 
vehicles will be subdivided into a number of space replaceable units to be 
serviced on-orbit. 

' \ 

The program will be written to allow a substantial variation in the 
input parameters, including the policies which determine when launches 
are actually made. Several forms of output from the computer program will 
be available. This output will be selectable and includes the ability to trace 
the history of a particular satellite as well as the ability to ascertain such 
summary statistics as number of launches, number of modules used, etc. 

The program is to be written for the CDC 7600 and to be compatible 
with the NASA CDC 3200 (32-bit word length) and the UNIVAC 1108 comput- 
ing systems. The program shall be designed for interactive operation from 
a remote terminal. Supporting documentation will be generated. 

The program will have the capability to accept various logistic 
vehicle definitions such that tradeoffs of operational costs can be performed. 
The vehicles will be described in terms of performance, mission time, and 
availability. The types of vehicles to be considered for servicing missions 
are the Shuttle, Tug, and Solar Electric Propulsion Stages (SEPS) and various 
combinations (i. e. , Tandem Tugs). Servicing missions shall include low 
altitude and geosynchronous orbits and certain multiple orbit operations. 

The East Coast and West Coast launch facilities will be treated in 
this simulation by making separate runs for each. This gives valid results 
provided the Shuttles and Tugs are not interchanged between the two launch sites 
The Department of Defense space traffic may be treated as a set of scheduled 
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launches of fixed mission duration. This imposes certain constraints on 
vehicle availability which must be recognized when assessing NASA missions. 
A single fleet will service both NASA and DOD operations although joint 
operations will not be performed. The simulation will test various fleet 
sizes and servicing policies, give cost comparisons, and test sensitivities of 
ground rules and input data. The output of the computer program will contain 
data on distribution of flights, availability of operational systems, loading 
efficiency, costs, etc. 
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2 . 


SUMMARY DESCRIPTION OF COMPUTER 
SUBROUTINES AND THEIR INTERACTION 


This section introduces some suggested portions of the computer 
program and defines their interaction. Detailed descriptions may be found 
in Section 5. Refer to Fig 1 for a graphic presentation of the interactions. 

A. DATA INPUT SUBROUTINE 

This subroutine is designed to ascertain from the user necessary 
data to define completely the problem. These inputs are detailed in the 
next section of the report. This subroutine communicates with most of 
the remaining subroutines by supplying inputs to these subroutines. These 
inputs define satellite and launch vehicle parameters, policies that are 
available, and desired output. 

B. MODULE FAILURE AND WARNING SUBROUTINE 

This subroutine will generate failure times and warning times for 
each SRU through the use of a random number process. Warning times are 
those times, generally preceeding SRU failure, when some indication is 
received from the SRU that a non-critical component has failed. Another 
type of indication is available by monitoring depletion of expendables. 

The program will accommodate active and dormant failure rates. The 
principal use of the outputs of this subroutine is to assist in defining the 
system status; that is, whether various satellites are operative. 

C. CURRENT SATELLITE SYSTEM STATUS SUBROUTINE 

This subroutine will contain the status of all satellites and each 
constituent SRU. This subroutine will also have the capability to monitor 
the availability of multi- satellite systems; that is, the state of each individual 
satellite within that system. The principal inputs to this subroutine will be 
initialization from the input subroutine and data relating to failed modules. 

In addition, information will come to this subroutine after the satellites 
have been serviced containing a new birth of time for that module. The 
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Figure 1. Simplified System Flow Diagram 












principal outputs from this subroutine will be to the Bookkeeping and Output 
Subroutine and the Tug Loading Subroutine. 

D. TUG CONSTRAINTS SUBROUTINE 

The Tug Constraints Subroutine calculates information relative to 
various constraints that determine how many modules and which types can 
be loaded on the Tug. In particular, constraints to be considered are the 
volume of the modules and the AV capability available to visit more than one 
satellite on a flight. Inputs to this subroutine are program inputs and the 
status of and requests from the Tug Loading Subroutine. The principal out- 
put to the Loading Subrouting delimits the loading possibilities. 

E. TUG LOADING SUBROUTINE 

Given that a number of modules have failed or have had warnings 
occur, the question becomes : how and when shall these modules be loaded? 

On which Tug shall they be loaded and in what order, and which satellites 
shall be visited by which Tug? The limitations imposed by the Tug constraints 
will determine in some cases which modules can be serviced on a particular 
flight. A number of loading possibilities exist and will be available at the 
user's option. For example, the Tug can be loaded with failed modules as 
the failures occur, with modules that have had warnings, or with only a 
single module if that module is important enough. In addition, scheduled 
flights, those which are not caused by failures or warnings, will also have 
to be integrated into the loading routine. The possibility of a Tug flight 
containing both satellites to be deployed as well as replacement modules for 
satellites in orbit will be considered. The program shall have the capability 
to indicate that specific payloads will be launched and/or retrieved using a 
tandem Tug. 

This subroutine will also consider limitations on the number of 
modules available on the ground. The pipeline of any particular supply of 
modules available is finite, and if no modules are available, it will not be 
possible to satisfy the failed satellite. It will then be necessary to wait 
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until a module becomes available as a result of either being manufactured or 
refurbished (after having been brought down from another satellite). The 
principal outputs of this subroutine are to the Launch Subroutine. 

F. LAUNCH SUBROUTINE 

In this subroutine, the launches of the loaded Tugs are queued up, 
and the order and timing of the launches are established according to the 
policies which form inputs to this subroutine. Constraints on the launch 
vehicles (established principally by the orbits of the satellites) as well as 
any other operational questions may enter into the policies. The principal 
outputs of this subroutine are to the Servicing Subroutine. 

G. SERVICING SUBROUTINE 

This subroutine takes the information from the Launch Subroutine, 
pertaining to modules and satellites that have been put into orbit and causes 
changes in the status of the modules and satellites in the Current Satellite 
System Status Subroutine. The servicing subsystem also changes the status 
of the Shuttle and Tug queues by returning vehicles to the queues following 
the flight. The principal outputs of this subroutine are to the Current 
Satellite System Status, Launch, and Tug Loading Subroutines. 

H. BOOKKEEPING AND OUTPUT SUBROUTINE 

Data from other sections of the program are centralized, assembled, 
and summarized in this subroutine. The subroutine should have the option 
of providing a number of degrees of detail so that users with different 
requirements can obtain the amount of detail they desire. This subroutine 
will also combine the statistical outputs with costing routines to provide 
costing data. 
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3. COMPUTER PROGRAM INPUT DATA 


This section delineates the input data required for the initiation and 
operation of the computer program. Reliability data is treated in the form of 
a Weibull distribution and its parameters, alpha and beta. The Weibull 
distribution takes the form of: Reliability (t) = e . The program should 

be written such that changes in data from one run to the next can be made 
without requiring that all data be input a second time. 

A. TOTAL TIME TO BE SIMULATED (<20 years) 

B. INPUT DATA FOR EACH SATELLITE (<999 satellites) 

1. List of modules (SRUs) comprising the satellite and for each 
module, the time the module is born, the warning time, and 
the failure time of the module 

2. Identification of the non- replaceable unit and its birth and 
failure time 

3. Total weight of the satellite 529, 500 kg (£65, 000 lb) 

4. Total volume of the satellite £311. 52m^ (£ll,000 ft^) 

5. Priority assigned to the satellite (yes or no) 

6. Number of satellites which comprise this satellite system 
( -16) 

7. Description of the orbit for the satellite (<99 possibilities) 

8. Complete schedule of launches, retrievals, and mission 
equipment changes for the satellite (total £ 40) 

9. Program termination time for the satellite (<20 years). 


C. 


D. 


FOR EACH SATELLITE SYSTEM 

1. Delineation of all satellites in this satellite system (<16) 

2. Criterion for operational system (e. g. , 3 out of 4). 

FOR EACH MODULE TYPE (<999 Types) 

1. The failure parameters' q^, 0 ^, and tt^ (os 999,|8£9, tt<20) 


-sc 

't* 

•JU U- 
'i' r r* 


tt^ is the truncation time on the reliability function. 

Similar values may be used for the dormant failure parameters. 
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2. The warning parameters a 0 , and tt (same as above) 

3. Weight of the module £453. 55 kg (<999 lb) 

4. Volume of the module £28. 29m^ (£999 ft^) 

5. Number of modules in the pipeline and availability date for 
each (£99) 

6. Time to repair a failed module (<1 year) 

E. SHUTTLE 

1. Number of Shuttles available for Tug flights (<3) 

2. Turn-around time after return of Shuttle (£0. 5 year) 

3. Launch delay (£0.5 year) 

4. Minimum time between Shuttle launches (<0. 5 year) 

5. Probability of successful launch. 

F. TUG (£9 Versions Including Multiple Stage Options) 

1. Number of Tugs available (£9) 

2. Turn-around time after each flight (<0. 5 years) 

3. Volume capacity < 3 1 1 . 52m 3 (< 1 1 , 000 ft 3 ) 

4. Number of modules capacity (£99) 

5. Weight of service equipment <453.55 kg (<999 lb) 

6. Information on payload - AV tradeoff (to be specified later) 

7. Specification of whether Tug is recoverable or expendable 

8. Criteria for launch of partially filled Tug (<9) 

9. Maximum wait before launch (Si year). 

G. POLICIES 

1. LOADING POLICIES 

a. Load Tug when sufficient modules have been identified 
as failed modules 

b. Load Tug when a single module has failed; complete Tug 
loading with warnings 

c. Load Tug with warnings when enough have occurred 
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d. Priority loading; for example, load all of one type of 
module 

e. Load Tug after some maximum waiting time measured 
from time first SRU or satellite is available for loading 
on Tug 

2. LAUNCH POLICIES 

a. Launch chronologically (according to time Tug has been 
filled) following some specified delay 

b. Launch Tug loaded with priority satellite in precedence 
over other Tugs (following some specified delay). 

3. VARIOUS COMBINATIONS OF THE ABOVE 
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4 . 


POLICIES FOR TUG LOADING AND LAUNCHES 

This section describes policies that determine which SRUs and 
satellites are loaded on which Tugs and when launches of the combined 
Shuttle/Tug system are made. A number of policies are under consideration 
for actual use and to the extent possible, the program should have the 
flexibility to include other policies similar to those presented here. 

A. POLICIES FOR TUG LOADING 

The first policy for loading the Tug is to fill the Tug to (a minimum 
of some fraction of) its total payload weight and volume constraints with 
failed modules. In this policy, only failed modules would be considered in 
the Tug Loading Subroutine, and the launch would take place when the 
subroutine had determined that a particular load was at least a given fraction 
(which would be a program input) of the Tug payload for that orbit and that 
number of satellites visited. 

A second Tug loading policy is to initiate a launch after any failure 
of a module and to fill the remaining capability of the Tug with modules that 
have had warnings. This is done by examining the Current System Status 
Subroutine for all modules that have had warnings and by choosing those that 
have had the longest time since warning. The number of modules to be 
chosen would be the largest number that have had warnings that could be 
accommodated on that flight after the failed module has been loaded. In this 
policy, a flight would be made each time a module failed. 

A third policy would fill (to some minimum fraction) the Tug with 
modules that have had warnings. Launches could occur in the absence of any 
failures. When a Tug was filled, it would be launched. If a failure occurred 
before the Tug was filled, the flight would be made with that failure and the 
warnings that had occurred prior to the failure. 

If a module is a priority module (which may mean that it is any 
module from a priority satellite or is a particularly critical module for a 
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non-priority satellite), it enters after some change in state (warning or 
failure) at the head of the queue of modules to be loaded on the Tug and 
committed to the appropriate orbit. If necessary, other modules will be 
off-loaded from that Tug. If the Tug is not filled when the priority module 
is included, additional modules will be chosen from the warning modules 
with the longest warning being loaded first. In this policy, the loaded Tug 
would then be immediately transferred to the Launch Subroutine so that 
launch could take place in an expeditious manner. 

In order to maintain a minimum level of service, it will be desirable 
to guarantee that no SRU or satellite is required to wait longer than a 
specified time before its Tug is moved to the launch queue. 

B. POLICIES FOR LAUNCH 

The first policy for launch involves launching the Tug in the order in 
which it arrives in the Launch Subroutine. Tugs come to the Launch Sub- 
routine, are queued up, and launches are made in a first-in, first-out 
manner. This same method would be used for Shuttle launches where Tugs 
are not employed. 

Priority Tugs can be moved to the head of the queue of Tugs, or more 
exactly, ahead of all non-priority Tugs but at the end of any queue of 
priority Tugs . 
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5. DEFINITION OF SUBROUTINES 


This section contains the detailed descriptions of the subroutines. 
Each detailed description is keyed to one or more system flow diagrams, 
and each block of each diagram contains a number which identifies that 
block and which is referred to in the text. Blocks representing input data 
from other subroutines are identified by enclosing that block in dashed lines. 
Blocks representing output data from the subroutine under consideration to 
other subroutines are represented by double -scoring the blocks. 

Descriptions given in this section often refer to the various sub- 
routines by the initials of the names of the subroutines. For the convenience 
of the reader, these abbreviations are summarized here: 


INSR 

Data Input Subroutine 

MFWSR 

Module Failure and Warning Subroutine 

CSSSSR 

Current Satellite System Status Subroutine 

TCSR 

Tug Constraints Subroutine 

TLSR 

Tug Loading Subroutine 

LSR 

Launch Subroutine 

SSR 

Servicing Subroutine 

OUTSR 

Bookkeeping and Output Subroutine 


There may be a number of ways to control the overall program 
timing available to the computer programmer. One is suggested here, 
although it is not necessarily meant to be the one chosen. Referring to 
Figure 1, it can be seen that the program may be divided into a number of 
separate subroutines. Among these subroutines, the ones that have events 
occur that may represent elapsed time are Current Satellite System Status 
Subroutine, Tug Loading Subroutine, Launch Subroutine, and the Servicing 
Subroutine. Events may occur following delays at various points within 
these subroutines. 

It is suggested that within the Bookkeeping and Output Subroutine, 
an Executive Timing Section be maintained to control events so that they 
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occur in the proper chronological order. This Executive Timing Section 
would take inputs from each of the four subroutines describing when the next 
action in that subroutine was scheduled to occur and would keep the chrono- 
logical ordering of the events consistent among the four subroutines. Action 
involving the Tug Constraints and Module Failure and Warning Subroutines 
does not involve elapsed time and need not be considered by the Executive 
Timing Section. 

A. DATA INPUT SUBROUTINE 

The purpose of the Data Input Subroutine is to take data from the 
program user describing the system to be simulated and to convert it to a 
format appropriate for other subroutines in the program and to direct the 
data to the appropriate subroutine. The Data Input Subroutine will also 
specify which outputs are required and which of the policy options previously 
delineated will be applied to the particular simulation. 

This subroutine will also initiate certain portions of the program 
at the start. For example, it will call for the generation of warning and 
failure times for all SRUs on orbit at the start of the simulation. 

As much as possible, the Data Input Subroutine should allow for 
flexibility. In particular, it should not be necessary to repeat data that 
does not change from one run to the next. The Data Input Subroutine should 
have the capability to accept data from a remote terminal. 

The exact form of this subroutine is dependent upon the computer 
language used. The listing of data to be supplied in this subroutine was 
given in Section 3 together with the limits to be expected for the data. The 
indication of which subroutines will use this data is given in the descriptions 
of these subroutines in subsequent parts of this section. 

B. MODULE FAILURE AND WARNING SUBROUTINE 

This subroutine is characterized by a particularly non-complex 
interface with the other subroutines (Refer to Figure 2). A request for a 
failure time and a warning time for a particular SRU is generated in the 
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Figure 2. System Flow Diagram, Module Failure And Warning Subroutine 







Current Satellite System Status Subroutine and sent to the Module Failure and 
Warning Subroutine. This is represented in Figure 2 by (1). Note that when 
the request for data is sent from CSSSSR, it must include the values for 
alpha, beta, and truncation time for both warning and failure functions. 

The flow of activity then generates the warning time t according to 
the equation given in (2). In order to calculate this, a random number 
denoted by N1 is generated in the random number generator (3). The numbers 
from this random number generator are uniformly distributed between zero 
and one. 

After the warning time t has been calculated, the next step cal- 
culates the failure time t^. This is done in (4) using random number inputs 
from the random number generator. The inputs are Nl, the same number 
used in (2), and also N2. A new pair of random numbers Nl and N2 is gener- 
ated for each request of a t w and t^. The outputs from (2) and (4) are inputs 
to (5) which corrects the calculated warning and failure times by adding the 
current system time (6) to those values so that the future warning and failure 
times reflect the correct starting time. The outputs from (5) go to CSSSSR (7). 

C. CURRENT SATELLITE SYSTEM STATUS SUBROUTINE 

The data identifying satellite and SRU parameters as well as their 
current status; e. g. , time of next failure of each satellite in the simulation, 
are stored in this subroutine. This subroutine also contains the clocking 
mechanism for the simulation. 

The data on each satellite can be divided into three portions (Refer 
to Figure 3). There are the fixed data on the satellite (1); e. g. , time the 
satellite was born, the orbital parameters, and the priority assigned to the 
satellite. A second set of data for the satellite is the fixed data for each 
SRU (2); e. g. , alpha, beta, and weight. A third set of data (3) for the 
satellite is the variable data for each SRU; in particular, the time that each 
SRU was born, will have a warning, and will fail. A complete list of data 
for these three portions is given in Table 1. The data come s from the Input 
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Figure 3. System Flow Diagram, Current Satellite System Status Subroutine 









Table 1. Satellite Data 


SATELLITE FIXED DATA 

1. List of SRUs comprising the satellite. 

2. Identification of the non-replaceable unit. 

3. Total weight of the satellite. 

4. Total volume of the satellite. 

5. Priority assigned to the satellite. 

6. Identification of other satellites which comprise this 
satellite system. 

7. Description of the orbit for the satellite. 

8. Complete schedule of launches, retrievals and mission 
equipment changes. 

9. Program termination time. 

SRU FIXED DATA 

1. The failure parameters, a 8^, and tt^. 

2. The warning parameters, 8^, and tt w> 

3. Weight of the module. 

4. Volume of the module. 

5. Number of modules in the pipeline and availability for each. 

6. Time to repair a failed module. 

SRU VARIABLE DATA 

1. Birth time. 

2. Warning time. 

3. Failure time. 
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Subroutine (4) in the cases of the fixed data and from the Module Failure and 
Warning Subroutine (5) in the case of the variable data. 

Data from (3) and also from the Current System Time (6) are used 
in (7) to determine the next SRU failure times and the warning times for 
each SRU. This could be done, for example, by ranking the failure times 
of all the SRUs in the system chronologically and stepping through the list 
until the first failure time is reached. At this point, data on that failure 
are sent to the Tug Loading Subroutine (8). 

Data in the Current Satellite Systems Status Subroutine are updated 
when a request comes from the Servicing Subroutine (9). This goes to (10) 
which now also will have received a request for data from (4) at the beginning 
of the program. In order to generate this data, information is received 
from (2) on the alphas, betas, and truncation times. These requests are 
sent to MFWSR (11). 

The Current Satellite System time is also sent to several other 
subroutines (11), (12). 

D. TUG LOADING SUBROUTINE 

This subroutine takes data pertaining to failed modules and scheduled 
flights and combines it with the constraints put upon the operation of the 
Tug to appropriately load the Tug and transfer it to the Launch Subroutine 
where it is combined with the Shuttle and launched. In this subroutine the 
word "Tug" is used in a generic sense and may refer toany of the several 
verisions of upper stages. If two or more Tugs are available in a single 
simulation run, the program will choose the appropriate one. However, 
criteria for the selection must be provided in such a case. 

Information that a failed module is available for loading comes 
from CSSSSR (1) (Refer to Figure 4). It is first necessary to determine if 
there is a replacement SRU in the inventory pipeline of SRUs (2). This is 
done by consulting the pipeline queue (3) which in turn is replenished by 
refurbished modules. Those data come from the Servicing Subroutine (4). 
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Figure 4. System Flow Diagram, Tug Loading Subroutine 














If the pipeline supply is not adequate, the data pertaining to the failed module 
are held in (5) until information from (4) indicates that a refurbished mpdule 
is available. When the pipeline supply is adequate, either as a result of (2) 
or (5), the appropriate Tug is identified (6). 

It is assumed that since the SRU is part of a particular satellite 
and since Tugs service particular satellites, this SRU can uniquely be 
identified with the particular Tug. We determine if this SRU can be loaded 
on the first available Tug suitable for its orbit (7). It should also be noted 
that the same question is asked of all scheduled flights (8) which are assumed 
to enter (7) according to their chronological time of birth. 

If the SRU or satellite cannot be loaded on the first Tug, which can 
be determined by consulting the Tug Constraints Subroutine (9), then it is 
appropriate to ask if any other Tug is available for this module to be loaded 
on (10). This can be determined by examining the queue of Tugs (11) to see 
if any are available. If there are no additional Tugs available (12), it is 
necessary to wait until information from the Tug queue (11) indicates that a 
Tug is available. When this happens or if the Tug was available earlier 
(when the decision was made in (10)), it must be ascertained if SRU can be 
loaded on this second Tug (13). If the answer is negative, the program 
loops looking again for additional Tugs until it either runs out of Tugs or 
finds one where the SRU or satellite, as the case may be, can be loaded. If 
the answer is positive (it can be loaded on the Tug), the activity moves to 
(14) loading the module or satellite on the Tug. The activity also moves to 
(14) if the answer to (7) was positive. At this point, the information on 
modules loaded on this Tug in TCSR is updated to add the new module. 

After the module is loaded on the Tug, it is appropriate to determine 
if this is a priority flight (15). If it is not a priority flight, then it must be 
determined if this module completes the loading of the Tug (16). This 
question requires an input from TCSR (25) identifying how many modules 
are loaded, what fraction of the volume is filled, and how much payload 
remains. If any of these exceed the limits from INSR (18), the loading is 
complete. At this point, it is possible to determine if the loading of expend - 
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ables for satellites now scheduled for servicing would complete the loading. 
Thus, a certain level of depletion would qualify SRUs with expendables for a 
space -available -basis replacement. One additional input to (16) concerns 
the maximum waiting time (17). In the event that a module has waited on a 
Tug more than a certain amount of time, the Tug is moved to the launch 
area. The inputs to (17) come from (14), the time the first module was 
loaded on the Tug, and from the Input Subroutine (18) which identifies how 
long a wait is allowed. If the answer to (16), does this complete Tug loading, 
is negative, a question of policy is asked. This question is: given that we 
have a reason to fill one part of the Tug, should the remaining part of the 
Tug be filled with warnings (10)? The answer to this question comes from 
the Input Subroutine (18). If the answer is negative, the program continues 
waiting for the next event (24). 

If the answer to the question concerning priority flights (15) or the 
Tug being filled with warnings (19) is positive, it ; is necessary to select the 
warnings and load the Tug (20). The warnings may be selected by choosing 
those with the longest waiting time; that is, those where the warnings occurred 
first. These data on warnings come from CSSSSR (21). 

The activity from (2 0) or from a positive answer to the question in 
(16) results in the complete loading of the Tug and the transfer of this Tug 
to the launch subroutine so that it can be mated with the Shuttle and launched 
(22). This action also leads to a reordering of the Tug queue (23) so the 
Tug that has just been transferred to t he Launch Subroutine is taken out o£ 
the queue, and the position of the remaining Tug is moved up to fill the empty 
spot left by the transferred Tug. 

E. TUG CONSTRAINTS SUBROUTINE 

It is not always possible to load a module on a Tug as soon as one 
has failed and a new module has been found to take its place. Rather in some 
cases, the payload and velocity limitations on the Tug will dictate that the 
module wait for a subsequent flight. Other types of contraints, in addition 
to the payload AV constraint, may also eliminate a module from a particular 
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Tug loading. This subroutine will determine whether a module can be 
loaded on a particular Tug. 

Information describing the candidate module and the Tug to be consid- 
ered for carrying that module arrives from the Tug Loading Subroutine (1) 
(Refer to Figure 5). The subroutine first determines if the modules exceed 
the constraint on the volume of the modules that can be loaded on the Tug (2). 

To do this, it is necessary to consult the inventory of items already loaded on 
that Tug (3). This might be stored as a table in (3). Information for construct- 
ing the table comes from the Tug Loading Subroutine (4) and is sent to the 
Tug Constraint Subroutine when the module is actually loaded. If the volume 
constraint has not been exceeded, we next determine if the payload AV 
constraint has been exceeded (5). This will be done in a separate portion of 
the program (6) to be specified elsewhere. If the payload AV constraint has 
not been exceeded, the output of this subroutine to the Tug Loading Sub- 
routine is to indicate that the constraint is not exceeded and that the module 
may be loaded on the Tug (7). If the answer in (2) or (5) was positive, the 
output is that this constraint has been exceeded and this module cannot be 
loaded on this Tug (8). 

F. LAUNCH SUBROUTINE 

In this subroutine, the Tug has been filled to a satisfactory limit, is 
joined with the first stage, and launched. Tugs going to different orbits 
may be queued up at one time waiting for an available Shuttle. 

Information that a loaded Tug has been created comes from the Tug 
Loading Subroutine (1) (Refer to Figure 6). The first consideration is whether 
or not a Shuttle is available to be mated with a Tug (2). This can be deter- 
mined by consulting the Shuttle queue (3) which is updated by the Servicing 
Subroutine (4). If the Shuttle is not available, it is appropriate to determine 
if this Tug is a priority Tug; i. e. , does it contain a priority satellite (5). If 
this answer is positive, then this Tug is moved ahead of non-priority Tugs 
waiting for an available Shuttle. Information on the availability of the Shuttle, 
comes from (3), 
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Figure 5. System Flow Diagram, Tug Constraints Subroutine 
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Figure 6. System Flow Diagram, Launch Subroutine 














If the answer to (2) was positive or after the Tug has waited for a 
Shuttle, the activity moves to (8) which represents the Tug being loaded on 
the Shuttle. After a specified time from INSR (14) has elapsed (9), the 
Shuttle can be launched provided it does not follow too closely the last launch 
(10). The assumption here is that two Shuttles cannot be launched arbitrarily 
close together. If the launch does not follow the last launch by the minimum 
time required (11), the Shuttle waits until that minimum time has elapsed 
and then the launch occurs (12). Information that this has occurred is then 
sent to the Servicing Subroutine (13). 

G. SERVICING SUBROUTINE 

This subroutine models the actual servicing or changing of the status 
of satellites in the program. It causes new birth times and death times to be 
generated for satellites via the Current Satellite System Status Subroutine. 

It also returns Tugs and Shuttles to availability queues. 

The Launch Subroutine indicates that a launch has taken place (1) 
(Refer to Figure 7). The success of the launch is determined first (2), based 
on an input probability of successful launch (3) and a random number (4). If 
the launch is not successful, all items are returned to queues to wait for 
future launches (5). If the launch is successful, the first satellite position 
is then visited (6). At this point, the servicing of that satellite is accomp- 
lished (7), and replaced modules from that satellite reenter the pipeline 
with a new date when they will become available (8). This date reflects 
the sum of current system time (9) and a period for refurbishment. 

After the first satellite position has been serviced, the subroutine 
determines if this is the final satellite position to be serviced this flight (10). 
If the answer is no, the subroutine visits the next satellite position. This 
looping is repeated until the answer to (10) is affirmative. The Shuttle is 
then assumed to be returning to earth, and it is necessary to determine 
which Tug, if any, it will carry. If the Shuttle carries the same Tug down 
that it carried up (11), all items can be returned to queues (12). If the 
Shuttle did deploy a Tug (13), that Tug is placed in a queue for Tugs holding 
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Figure 7. System Flow Diagram, Servicing Subroutine 















on-orbit waiting to be returned (14). If the Shuttle is to return a Tug to 
earth (15), the Tug is removed from the holding queue (16). At this point, 
the Tug and Shuttle are returned to their respective queues, assigned new 
availability dates, and the service flight is terminated (17). 

H. BOOKKEEPING AND OUTPUT SUBROUTINE 

Data from other subroutines will be collected and summarized in 
the Bookkeeping and Output Subroutine. The operation of this subroutine 
will be specified by the program user who will indicate the level of detail 
desired as well as specific outputs he wishes to receive. This subroutine 
will combine the statistical outputs with costing routines to provide costing 
data. The flexibility to allow different costing approaches will be main- 
tained. The detailed list of possible outputs is contained in Section 6. 

The system flow diagrams given in earlier subsections do not in 
general indicate where data must be taken for the Bookkeeping and Output 
Subroutine. This is dependent on the form of the computer programming. 

The executive timing section may also be part of this subroutine. 
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6 . 


COMPUTER PROGRAM BOOKKEEPING AND OUTPUTS 


In addition to outputs calculated by the program, the output from the 
computer should summarize to a limited extent the input parameters. In 
particular, there should be provision for printing a descriptor for the case 
simulated as well as any appropriate remarks and, at the user's option, any 
of the other input data. 

One of the user's options for output data will be a complete history of 
all major events that took place during the simulation. Major events include 
the birth and death of each module, the time and contents of each Tug flight, 
and the various waiting times of modules and launch vehicles within queues. 

Among the other outputs available to the user, the following may 
be selected: 

1. Availability of each satellite 

2. Availability of each system of satellites 

3. Number of flights to each satellite 

4. Number of each type of module used 

5. Number of times a module was requested when the pipeline 
was empty 

6. Average time spent in pipeline by module 

7. Number of Tug flights 

8. Number of times a Tug was requested and not available 

‘9. Average wait for Tug 

10. Number of times the Shuttle was requested and not available 

11. Average wait for Shuttle 

12. Average waiting time between satellite outage and resupply 

of the satellite 

13. Average utilization of Tug capacity 

14. Number of times non-replaceable unit failed 

15. Number of flights involving a priority satellite 
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16. Breakdown of total flights by orbit 

17. i Breakdown of total number of flights by Tug type 

18. Average wait for launch of scheduled items 

19. Standard deviation for above average values (from multiple 
runs) 

20. Costs. 
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